Skip to content

Clarify and fix construction of foreign key column names #1324

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 5 commits into from

Conversation

schauder
Copy link
Contributor

@schauder schauder commented Sep 7, 2022

This PR fixes 2-3 issues, depending on counting.
Only parts of it should be back ported.

The first commit "The back reference generation is now configurable."
Closes #1161.
Technically it also closes #1147, which asks for documentation of the current state.
This should get back ported at least to 2.4

The second commit "New default behaviour for back reference naming." switches the default behaviour.
Closes #1162
Since this is a breaking change it should not be back ported.

Sorry for the confusion.

@schauder schauder requested a review from mp911de September 7, 2022 09:27
The default version is the behavior that existed so far:
The back reference is the table name as generated by the `NamingStrategy` without taking `@Table` annotations into account.

The new alternative is to take `@Table` into account.

The behavior can be configured by setting the `foreignKeyNaming` property on the `RelationalMappingContext`.

Closes #1161
Closes #1147
The new default is to take `@Table` annotations into account.

The behaviour can be configured by setting the `foreignKeyNaming` property on the `RelationalMappingContext`.

Closes #1162
See #1147
@mp911de mp911de force-pushed the issue/1147-fk-naming branch from 94e31cf to 88485c1 Compare October 5, 2022 11:07
Do not expose setForeignKeyNaming methods on NamingStrategy to make less assumptions about how a naming strategy gets implemented. Provide getRequiredLeafEntity method on PersistentPropertyPathExtension to reduce null and state assertion checks.

Refine getTableName/getQualifiedTableName approach to reduce API surface and avoid deprecations.
@mp911de mp911de force-pushed the issue/1147-fk-naming branch from 88485c1 to c407ff0 Compare October 5, 2022 12:02
mp911de pushed a commit that referenced this pull request Oct 5, 2022
See: #1315
Original pull request: #1324.
mp911de pushed a commit that referenced this pull request Oct 5, 2022
mp911de added a commit that referenced this pull request Oct 5, 2022
Use consistent method and argument names for newly introduced methods. Reorder and group template API methods to keep related methods together.

See: #1315
Original pull request: #1324.
mp911de added a commit that referenced this pull request Oct 5, 2022
schauder added a commit that referenced this pull request Oct 5, 2022
See: #1315
Original pull request: #1324.
schauder added a commit that referenced this pull request Oct 5, 2022
schauder pushed a commit that referenced this pull request Oct 5, 2022
Use consistent method and argument names for newly introduced methods. Reorder and group template API methods to keep related methods together.

See: #1315
Original pull request: #1324.
schauder pushed a commit that referenced this pull request Oct 5, 2022
Copy link
Contributor Author

@schauder schauder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found a few things to complain about.

Nothing important though.
The general change looks very nice.

@@ -778,8 +777,8 @@ void selectByQueryValidTest() {
String generatedSQL = sqlGenerator.selectByQuery(query, parameterSource);
assertThat(generatedSQL).isNotNull().contains(":x_name");

assertThat(parameterSource.getValues()) //
.containsOnly(entry("x_name", probe.name));
assertThat(parameterSource.getValues()).hasSize(1) //
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really don't like this change. It does essentially the same assertion but in two pieces. I find the original version clearer and easier to understand.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me roll back those changes to simplify things.

* The fully qualified name of the table this path is tied to or of the longest ancestor path that is actually tied to
* a table.
*
* @return the name of the table. Guaranteed to be not {@literal null}.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should also have a since annotation, shouldn't it?

.map(Table::schema)
.filter(StringUtils::hasText)
.map(this::createSqlIdentifier));
this.tableName = Lazy.of(() -> Optional.ofNullable(findAnnotation(Table.class)).map(Table::value)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should protect these line breaks with comments.


RelationalMappingContext mappingContext = new RelationalMappingContext();
private RelationalMappingContext mappingContext = new RelationalMappingContext();
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought we don't make stuff private in tests.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have no strong guidance about private/non-private. This is mostly an effect of the JUnit 5 migration aid that reduces visibility to the lowest possible visibility requirement.

@mp911de mp911de added the type: enhancement A general enhancement label Oct 7, 2022
@mp911de mp911de added this to the 3.0 RC1 (2022.0.0) milestone Oct 7, 2022
@mp911de mp911de changed the title clarify and fix construction of fk column names. Clarify and fix construction of foreign key column names Oct 7, 2022
mp911de pushed a commit that referenced this pull request Oct 7, 2022
The default version is the behavior that existed so far:
The back reference is the table name as generated by the `NamingStrategy` without taking `@Table` annotations into account.

The new alternative is to take `@Table` into account.

The behavior can be configured by setting the `foreignKeyNaming` property on the `RelationalMappingContext`.

Closes #1161
Closes #1147
Original pull request: #1324.
mp911de pushed a commit that referenced this pull request Oct 7, 2022
The new default is to take `@Table` annotations into account.

The behaviour can be configured by setting the `foreignKeyNaming` property on the `RelationalMappingContext`.

Closes #1162
See #1147
Original pull request: #1324.
mp911de pushed a commit that referenced this pull request Oct 7, 2022
See #1162
Original pull request: #1324.
mp911de added a commit that referenced this pull request Oct 7, 2022
Do not expose setForeignKeyNaming methods on NamingStrategy to make less assumptions about how a naming strategy gets implemented. Provide getRequiredLeafEntity method on PersistentPropertyPathExtension to reduce null and state assertion checks.

Refine getTableName/getQualifiedTableName approach to reduce API surface and avoid deprecations.

See #1147
Original pull request: #1324.
@mp911de
Copy link
Member

mp911de commented Oct 7, 2022

That's merged and polished now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement A general enhancement
Projects
None yet
2 participants